Business workflow or process-oriented software applications are often used to manage how different entities with organizational roles (e.g., persons or individual) interact with various tasks such as in workflow processes. For example, in a typical purchase order fulfillment workflow process, an order fulfillment clerk may be responsible for receiving the order from a customer; a manager of the customer's region may be in charge of approving the order; an inventory manager may have the duty to identify the availability of the ordered product; and a shipping department manager processes the shipment of orders. In many instances, any individual in the same role, such as a manager, may perform the task. However, business workflow software applications need to resolve situations where a specific individual of a specific role must perform a particular task. For example, an expression such as “this.customer.region.manager” requires an identification of the individual who is entitled to play the role for this particular workflow instance.
While the workflow application may specify different entities or actors (e.g., the order fulfillment clerk, the sales manager, or the like) for performing a task, information relating to each of these entities may be managed by another system, such as a personnel directory managing system or a directory data source. Such personnel management system or data source includes personnel role information, including personnel access restrictions, task assignment rights and privileges, task delegation rights, and the like.
Currently, the workflow application and the personnel management system do not interact with each other efficiently such that the workflow application has information relating to entities of the personnel management system or a data source. For example, a workflow process definer, or modeler, who defines an order management process may wish to ensure that a particular task “must be approved by a second level manager of the initiator of this process instance.” Suppose a purchase order process is initiated by a fulfillment clerk, and that there are four different departments in the organization, each with a different organizational hierarchy maintained by the personnel management system. Within each department, the second level manager of the fulfillment clerk may be a different person and may perform a task specific to the department. For example, a second level manager in the sales department may “approve” an order initiated by a sales fulfillment clerk while a second level manager in the accounting department does not “approve” but rather “supervises” an accounting fulfillment clerk's tasks. Consequently, the workflow process definer in this example is required to statically specify a separate role-task logic to each department.
As illustrated in the example above, in addition to requiring knowledge of relationships, conventional workflow applications and other business systems need to resolve role definitions within the relationships of the personnel management system. For example, role definitions include references to information such as relationships between personnel and business entities and entities in the workflow system itself. The example “this task must be approved by the manager of the region in which this customer is situated”, which may be expressed as “this.customer.region.manager”, illustrates that the role resolution requires both the entities known to the workflow (i.e., “this customer”) and the relationships that are known only to personnel and business systems (i.e., what region does this customer reside it, and who is the region manager).
Some workflow applications and personnel role management software applications interact with one another to establish relationships between the entities of the workflow applications and personnel role management software applications. However, it is required that both sets of applications are manufactured or designed by the same manufacturer. In other words, information relating to relationships among entities or personnel hierarchy structure is unavailable to a third party workflow software.
Other directory access software or protocols attempt to make role information available from the role management software application. In addition, such directory access software may retrieve and access basic information (e.g., first name, last name, or the like) from online phone books across platforms. These attempts, however, are inefficient and fall short of providing information about how people are associated with non-people entities like regions (manager of region) and products (designer of this product). Without being able to access to this information, it is difficult for developers to establish relationships between roles and entities in the workflow management application and roles and entities in other applications in the business.
In addition, even when the information relating to entities is available (e.g., via generic access such as open database connectivity (ODBC), integration adapter methods, Web Service operations, and custom APIs), the burden of creating business role expressions falls heavily on the developer who implements the process per the developer's higher-level model diagrams and instructions. Using the example above, in order to design the task “must be approved by a second level manager of the customer's region of an initiator of this process instance”, a workflow process definer is required to resolve relationships between “second level”, “manager”, “initiator”, and the “manager of the customer's region”. Currently, not only is such relationship information unavailable; even if available, the information does not expose methods to help the definer reduce the burden in creating business role expressions.
Also, current systems and implementations are deficient and lack flexibility because the defined complex business role expressions are unique and specific to the particular business role expression. Thus, different definers, while defining a role expression for a similar or identical relationship as another definer, may not use the same role expression as another definer because different definers in different domains write code for the same purpose/task very differently. Moreover, the readability of the current process model is low as there is no uniformity in designing and defining role expression. To a non-technical user of a workflow process application, attempting to understand proper relationships between entities from arbitrarily crafted rules or codes further complicate the matter.